The present invention relates generally to remote procedure calls in a distributed computing system. More specifically, the present invention relates to a method and a system for managing remote procedure calls in a distributed computing system, based on an event-driven mechanism.
Computer applications include one or more program units, such as a function or a procedure, hereinafter referred to as procedures. Each procedure includes a block of programming codes that implement an operation or functionality on a set of values, hereinafter referred to as parameters.
A procedure may be located on the same node as the application program. Alternatively, the procedure may be located on a remote node. A procedure-based model of application processing enables the execution of a computer application on disparate computational devices. The remote procedure call system, therefore, enables the application program being executed on one computer, hereinafter referred to as client-computational node, to execute a desired procedure located on a remote computational node, hereinafter referred to as server-computational node.
In a distributed computing system, server-computational nodes publish a list of services they can offer to client-computational nodes. In a distributed computing system, multiple client interactions are active on a server-computational node. The server-computational nodes in the prior art implement the remote procedure call system by using a multi-threaded environment, spawning a separate thread of execution for each client request.
In the remote procedure call systems known in the prior art, the multiple threads of execution share the processing time of the processor, based on an algorithm. However, as the number of threads being simultaneously processed on a server-computational node increases, thread swapping becomes inefficient. For example, a thread may be blocked, waiting for an action from a thread that is progressing very slowly due to a large number of threads being supported under time slicing. In addition to the above, each thread requires its own stack for processing, which increases memory overheads at the server-computational node.
The two most important overheads associated with switching of thread are context switching and storage management.
Context switching includes storing the present state of a running thread and retrieving the old state of a sleeping thread. The actual information stored and retrieved may include a range of chip registers including, for example, general registers, segment registers, and so forth. Therefore, context switching involves changing a large amount data, which makes it a very expensive operation in an operating system.
Another challenge being faced by the programmers is to maintain the performance of massively threaded applications by reducing the storage management overhead. A stack is allocated for each thread. The specifics of stack management are implementation dependent. However, a stack size always has to be big enough to handle a wide range of potential calling patterns and therefore, it is always much larger than the actual data space required to store the data.
In a multithreaded environment the discrete state of a process is indeterminable. Moreover, the value an entity shared across multiple threads cannot be precisely determined. Thus, the principle of multithreading is not only complex and hence error-prone, but also inefficient. Several reasons that make multithreading error prone include deadlocks, race conditions, failure of synchronization, and so on.
Most importantly, in the case of processors that do not support hyper threading and similar techniques, multithreading is just an illusion of concurrency. The operating system provides the illusion of concurrency by rapidly switching between multiple threads of execution running on the server-computational node at a predefined interval of time, called a time slice. The length of the time slice for which a thread of execution is allowed to use the processor becomes an important parameter for a system designer. The time slice has to be small enough so that the end user actually gets the illusion of concurrency, and at the same time it has to be large enough for a program to complete a meaningful amount of work per time slice. Moreover, the switching of threads burdens the system with additional overheads and degrades the performance.
In light of the above discussion, there is need to address the numerous problems related to a multithreaded remote procedure call system.